Programming Elixir : Stateful Processes and Tail-Call Optimization

In Elixir, processes are short-lived by default; once a function finishes, the process terminates. To create a persistent, stateful process, we use recursion to keep the process alive in a loop.

1. Tail-Call Optimization (TCO)

If the absolute final action of a function is to call itself, the Erlang VM (BEAM) performs Tail-Call Optimization. Instead of adding a new frame to the stack, it simply jumps back to the start of the function with new arguments.

def factorial(n, acc), do: _fact(n-1, acc*n) # TCO
def factorial(n), do: n * factorial(n-1) # NOT TCO

2. Persistent State

State is maintained by passing updated values as arguments to the recursive call. Because of TCO, these arguments replace original parameters on the stack without consuming additional memory, allowing loops to run indefinitely.

TERMINAL bash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

What is the primary requirement for Tail-Call Optimization to occur?

The function must use the 'loop' keyword.

The recursive call must be the absolute final expression executed.

The function must be defined inside a module.

Arguments must be integers.

QUESTION 2

Exercise: WorkingWithMultipleProcesses-1. Run the Spawn1 and Spawn4 code. See if you get comparable results. What is the observable difference?

Spawn1 crashes after one message; Spawn4 stays alive.

Spawn1 is faster than Spawn4.

Spawn4 uses more memory over time.

There is no observable difference.

QUESTION 3

In pmap, we assign 'self' to 'me' before spawning. Why?

To make the code more readable.

Because 'self' inside a spawn block refers to the child process PID.

To bypass the Pin operator requirements.

QUESTION 4

Use spawn_link to start a child that sends a message and exits. If the parent sleeps for 500ms before receiving, what happens to the message?

The message is lost because the parent wasn't waiting.

The message is stored in the parent's mailbox until processed.

The parent crashes immediately.

QUESTION 5

Is the order of replies in concurrent processes deterministic in theory?

Yes, they always arrive in spawn order.

No, it depends on the scheduler and execution time.

Case Study: Token Exchange Persistence

WorkingWithMultipleProcesses-2

You need to spawn two processes that receive unique tokens ('fred' and 'betty') and send them back. You must ensure the results are gathered in the correct order even if the processes finish at different times.

How can you make the order of received tokens deterministic in practice?

Solution:
By capturing the PIDs of the spawned processes and using the Pin operator (^pid) in the receive block. This forces the parent to wait for the message from a specific PID before moving on to the next, regardless of which message is at the top of the mailbox.

Write the logical structure for a persistent 'Token' receiver using TCO.

Solution:
The receiver should be a function (e.g., 'loop') that contains a 'receive' block. After processing the token and sending it back, it must call 'loop()' as the final statement. This allows the process to handle multiple tokens over its lifetime without crashing the stack.